<!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN""http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html lang="zh" xml:lang="zh" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<head>
<META http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Concept: Solution Partitioning</title>
<meta name="uma.type" content="Concept">
<meta name="uma.name" content="solution_partitioning">
<meta name="uma.presentationName" content="Solution Partitioning">
<meta name="element_type" content="concept">
<meta name="filetype" content="description">
<meta name="role" content="">
<link rel="StyleSheet" href="./../../../css/default.css" type="text/css">
<script src="./../../../scripts/ContentPageResource.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/ContentPageSection.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/ContentPageSubSection.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/ContentPageToolbar.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/contentPage.js" type="text/javascript" language="JavaScript"></script><script type="text/javascript" language="JavaScript">
					var backPath = './../../../';
					var imgPath = './../../../images/';
					var nodeInfo=null;
					contentPage.preload(imgPath, backPath, nodeInfo,  '', false, false, false);
				</script>
</head>
<body>
<div id="breadcrumbs"></div>
<table border="0" cellpadding="0" cellspacing="0" width="100%">
<tr>
<td valign="top"><a name="Top"></a>
<div id="page-guid" value="1.6501323286225543E-305"></div>
<table border="0" cellspacing="0" cellpadding="0" width="100%">
<tr>
<td class="pageTitle" nowrap="true">Concept: Solution Partitioning</td><td width="100%">
<div align="right" id="contentPageToolbar"></div>
</td><td width="100%" class="expandCollapseLink" align="right"><a name="mainIndex" href="./../../../index.htm"></a><script language="JavaScript" type="text/javascript" src="./../../../scripts/treebrowser.js"></script></td>
</tr>
</table>
<table width="100%" border="0" cellpadding="0" cellspacing="0">
<tr>
<td class="pageTitleSeparator"><img src="./../../../images/shim.gif" alt="" title="" height="1"></td>
</tr>
</table>
<div class="overview">
<table width="97%" border="0" cellspacing="0" cellpadding="0">
<tr>
<td width="50"><img src="./../../../images/concept.gif" alt="" title=""></td><td>
<table class="overviewTable" border="0" cellspacing="0" cellpadding="0">
<tr>
<td valign="top">In this concept, we discuss the principles of partitioning a system into logical clusters of elements based on various organizing concerns. Those concerns may reflect business boundaries, physical boundaries, or more abstract subject matter boundaries.</td>
</tr>
</table>
</td>
</tr>
</table>
</div>
<div class="sectionHeading">Relationships</div>
<div class="sectionContent">
<table class="sectionTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<th class="sectionTableHeading" scope="row">Related Elements</th><td class="sectionTableCell">
<ul>
<li>
<a href="./../../../rup_soa_plugin/tasks/identify_services_565F8B8A.html" guid="{0BF79161-A484-4C48-B72D-DA381DA05886}">Identify Services</a>
</li>
<li>
<a href="./../../../rup_soa_plugin/tasks/soa_service_design_AB6BA763.html" guid="{9EB2B302-79F6-4DF8-AEB7-98E6AC1756DD}">Service Design</a>
</li>
<li>
<a href="./../../../rup_soa_plugin/workproducts/soa_svce_model_svce_partn_DC19AD3F.html" guid="{C302AF5A-1591-4F26-94E5-C412866553BF}">Service Partition</a>
</li>
<li>
<a href="./../../../rup/tasks/describe_distribution_9BA1477C.html" guid="{6A112808-0A90-427A-BAB9-E14F3FBF72B5}">描述分布</a>
</li>
</ul>
</td>
</tr>
</table>
</div>
<div class="sectionHeading">Main Description</div>
<div class="sectionContent">
<table class="sectionTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<td class="sectionTableSingleCell"><h3>
    <a id="Introduction" name="Introduction">Introduction</a>
</h3>
<p>
    Much has been written about the decomposition of software designs into components or subsystems. Much has also been
    written about the need to understand the deployment topology required by an application early in its lifecycle so that
    correct architectural decisions can be made. However, there are very few mechanisms identified or used today to help in
    the logical partitioning of a system during architectural analysis such that decisions regarding the logical topology
    of a solution and the constraints imposed by non-functional requirements can easily be addressed at the model level
    before generation of detailed design and implementation work products. The following page outlines a set of simple
    model elements that allow for this reasoning. While they were developed with <i><a class="elementLinkWithUserText" href="./../../../rup_soa_plugin/guidances/concepts/service-oriented_architecture_8328ABAD.html" guid="8.613638237693525E-307">service-oriented solutions</a></i> in mind, these techniques are applicable to any
    software architecture modeling.
</p>
<h3>
    <a id="Partitions_and_Layers" name="Partitions_and_Layers">Partitions and Layers</a>
</h3>
<p>
    The following definitions are taken from the Neusoft Unified Process (RUP) glossary and contrast the notions of layers
    and partitions. Interestingly enough the term <i>tier</i>, while common in describing the logical architecture of a
    solution, does not appear in the NUP glossary.
</p>
<blockquote>
    <dl>
        <dt>
            <b>Layer</b>
        </dt>
        <dd>
            (1) A specific way of grouping <i>packages</i> in a model at the same level of abstraction.
        </dd>
        <dd>
            (2) The organization of <i>classifiers</i> or <i>packages</i> at the same level of abstraction. A layer
            represents a horizontal slice through an architecture, whereas a partition represents a vertical slice.
        </dd>
        <dt>
            <b>Partition</b>
        </dt>
        <dd>
            (1) <i>activity graphs</i>: A portion of an activity graphs that organizes the responsibilities for actions.
            See also: <i>swimlane</i>.
        </dd>
        <dd>
            (2) <i>architecture</i>: A subset of classifiers or packages at the same level of abstraction. A partition
            represents a vertical slice through an architecture, whereas a layer represents a horizontal slice.
        </dd>
    </dl>
</blockquote>
<p>
    So, a partition contains a set of elements representing some part of the architecture, but how does the <i>Software
    Architect</i> slice a model? The answer is deceptively simple: Partitions and layers are organizational constructs; at
    an architectural level they only represent logical organization. So, what aspects of the organization of a solution do
    you wish to represent? For example if the model view you are developing is concerned with security then you may wish to
    represent Trust Zones [JOHNSTON].
</p>
<p>
    For more information see the concepts <i><a class="elementLink" href="./../../../rup/guidances/concepts/layering_59FD1CD4.html" guid="3.801315327549898E-305">分层</a></i> and <i><a class="elementLink" href="./../../../rup/guidances/concepts/distribution_patterns_5A01CAF5.html" guid="6.137181182978733E-305">分布模式 </a></i> .
</p>
<h4>
    What can a partition represent?
</h4>
<p>
    As we said above, a partition may be used to represent any particular organization concerns the architect may wish to
    focus on. The following are common views that are constructed in a model. Note that one key aspect of partitions is
    that they do not imply ownership/containment and so a service may appear in multiple partitions simultaneously.
</p>
<blockquote>
    <b>Logical Solution Organization</b>; in this case the partitions represent the logical clustering of elements in a
    given solution. For example, in a business application we might use partitions to represent the separation into user
    interaction services, business services, and infrastructure services. Such a view corresponds more to the use of layers
    in NUP to describe tiers of an application. However, as services are not easily layered in the same way as a component
    or object-based solution, we use partitions. For more information on these service classifications, see the concept
    <i><a class="elementLink" href="./../../../rup_soa_plugin/guidances/concepts/service_portfolio_52FD64AC.html" guid="1.851952881072508E-305">Service Portfolio</a></i>.
</blockquote>
<p align="center">
    <img height="257" alt="Diagram is described in the textual content." src="./../../../rup_soa_plugin/guidances/concepts/resources/co_soa_partitioning-01.gif"     width="430" border="0" />
</p>
<blockquote>
    <b>High-Level Physical Distribution</b>; in this case partitions may be used to denote local versus remote services, at
    least when physical distance imposes constraints on the architecture. For example, noting that the customer, account,
    and order services are hosted in our primary data center and that the Electronic Data Interchange (EDI) gateway is
    hosted in a secondary data center is important when we also discover that the bandwidth connection between these
    centers is managed and we have to carefully control communication between these partitions.
</blockquote>
<blockquote>
    <b>Business Application/Ownership Boundaries</b>; in this case, partitions are used to represent ownership of services
    by a business area or by an application area. For example, we might denote that certain services are "owned" by Human
    Resources, some by Sales, and some by Marketing. Now, while this is not an architectural concern, most projects have to
    deal with aspects that do not involve technology or architecture but the social and political aspects of the
    organization. Partitions in this respect allow us to see how interaction between services crosses such boundaries and
    may impact the development process by requiring stakeholder support for cross-organizational change.
</blockquote>
<blockquote>
    <b>Business Process Boundaries</b>; in this case we represent end-to-end process areas with partitions, in effect
    grouping services by the processes they support. The diagram below contrasts the process view (shaded) with the
    business application/ownership view represented as the vertical bars. It is important in many cases to relate these two
    views of services already deployed and services planned by a project. 
    <p align="center">
        <img height="194" alt="Diagram is described in the textual content." src="./../../../rup_soa_plugin/guidances/concepts/resources/co_soa_partitioning-04.gif"         width="409" border="0" />
    </p>
    <p>
        This relationship between the vertical business area and the cross-business process is important to understand how
        each business area provides services to the processes that actually run the business. In respect to our example,
        this view regroups the services we identified earlier into new partitions as shown below.
    </p>
</blockquote>
<p align="center">
    <img height="158" alt="Diagram is described in the textual content." src="./../../../rup_soa_plugin/guidances/concepts/resources/co_soa_partitioning-02.gif"     width="400" border="0" />
</p>
<p>
    For more information on the connection between process modeling and service identification see the task <i><a class="elementLink" href="./../../../rup_soa_plugin/tasks/identify_services_565F8B8A.html" guid="{0BF79161-A484-4C48-B72D-DA381DA05886}">Identify Services</a></i>.
</p>
<h3>
    <a id="Service_Partitions" name="Service_Partitions">Partitions in the Service Model</a>
</h3>
<p>
    In the <i><a class="elementLink" href="./../../../rup_soa_plugin/workproducts/soa_service_model_623494B9.html" guid="{E24679B7-19F1-483B-A1F1-578839C43888}">Service Model</a></i> a particular model element, the <i><a class="elementLink" href="./../../../rup_soa_plugin/workproducts/soa_svce_model_svce_partn_DC19AD3F.html" guid="{C302AF5A-1591-4F26-94E5-C412866553BF}">Service Partition</a></i>, is used to model logical partitions. The UML
    2.0 representation for partitions is based on the use of the Node model element and uses composite structure to define
    the services in a partition and the communication between them..The <i><a class="elementLink" href="./../../../rup_soa_plugin/workproducts/soa_svce_model_svce_partn_DC19AD3F.html" guid="{C302AF5A-1591-4F26-94E5-C412866553BF}">Service Partition</a></i> element is shown in the pictures above and may
    contain not only instances of <i><a class="elementLinkWithUserText" href="./../../../rup_soa_plugin/workproducts/soa_svce_model_svce_provider_C00D3410.html" guid="{8427751F-3C14-4CEB-9816-5112BDB91EED}">Service Providers</a></i> but also instances of other partitions and so
    may be further composed where appropriate. A service partition may also specify one or more <i><a class="elementLinkWithUserText" href="./../../../rup_soa_plugin/workproducts/soa_svce_model_svce_gtway_4D9ADED2.html" guid="{B0BF4414-0382-4605-9EE9-82F0DEC7292C}">Service Gateways</a></i> which are named and typed UML 2.0 ports. These
    ports are typed by <i><a class="elementLinkWithUserText" href="./../../../rup_soa_plugin/workproducts/soa_svce_model_svce_spec_37E89A91.html" guid="{20F06B5E-95D5-422C-AB68-7C213D28533A}">Service Specifications</a></i> in the same way a <i><a class="elementLink" href="./../../../rup_soa_plugin/workproducts/soa_svce_model_service_1EE4C96C.html" guid="{FF65B0A2-6C53-4F01-9727-AACDB0D542C8}">Service</a></i> is and thus can be perceived as virtual services
    specifying the interface to a partition.
</p>
<p>
    So, for example it might be appropriate to note that the order management process area is accessed by the same
    interface to the order entry service provider in the diagram above. We term this promoting the interface from the
    service out to the partition. The following diagram depicts this and shows how the order entry service provider
    communicates with the other services in the partition.
</p>
<p align="center">
    <img height="158" alt="Diagram is described in the textual content." src="./../../../rup_soa_plugin/guidances/concepts/resources/co_soa_partitioning-03.gif"     width="198" border="0" />
</p>
<p>
    One capability of the service gateway is the ability to mediate communication bindings between clients on the outside
    of a partition and services on the inside. This allows for services to only deal with certain protocol bindings within
    a partition, for example to use a higher performance or more secure protocol within the boundaries and to expose
    certain capabilities to clients over a different protocol. For more information see the guideline <i><a class="elementLink" href="./../../../rup_soa_plugin/guidances/guidelines/service_mediation_2F2C4C02.html" guid="2.5614739075754752E-306">Service Mediation</a></i>.
</p>
<p>
    Note also that as the partitions are based on the use of UML 2.0 Composite Structures, there is no "containment"
    relationship between the partition and the services, it is possible, as we have shown above, to represent the same
    services in multiple partitions or views. If this flexibility is tied to the capability of service gateways, the
    software architect and designer can cluster services in logical groupings and allow service gateways to expose only
    relevant interfaces to clients.
</p>
<h3>
    <a id="Strict_Partitions" name="Strict_Partitions">Specifying Strict Partitions</a>
</h3>
<p>
    A strict partition is a partition where all services within the partition are accessed by clients/services outside the
    partition through service gateways. This implies that the service partition has its own set of interfaces and as such
    it may be seen as a logical higher-level service provider. This is particularly useful for partitions that represent
    either business application boundaries or business process boundaries. It also allows for the process represented to
    identify the interfaces it exposes to the rest of the business and which of the services supporting the process area
    are made publicly available. The order-management partition above is a strict partition, but the concept of
    "strictness" can only be assessed by evaluating a partition and is not a property of the model element itself.
</p>
<h3>
    <a id="References" name="References">References</a>
</h3>
<p>
    [<a id="Ref_Johnston" name="Ref_Johnston">JOHNSTON</a>] Simon Johnston, <a class="elementLinkWithUserText" href="./../../../rup_soa_plugin/guidances/whitepapers/modeling_security_concerns_in_service-oriented_architectures_3961AE50.html" guid="1.328991553095394E-305"><i>Modeling Security Concerns in Service-Oriented Architecture</i></a>. IBM
    developerWorks 2004.
</p></td>
</tr>
</table>
</div>
<table class="copyright" border="0" cellspacing="0" cellpadding="0">
<tr>
<td class="copyright">Copyright &copy; 2008 版权所有 东软集团股份有限公司&nbsp; 联系邮箱:<a href="mailto:tcoe@neusoft.com">tcoe@neusoft.com</a></td>
</tr>
</table>
</td>
</tr>
</table>
</body>
<script type="text/javascript" language="JavaScript">
				contentPage.onload();
			</script>
</html>
